Thanks for starting to think about debug extensions. Could you say what the plans are for developing Sdtrig? The current draft is very far from complete.

Yes I am currently working on it thats why its a draft PR. I am trying to complete this ASAP. Will keep you posted about progress.

Test Results

712 tests  ±0   712 ✅ ±0   0s ⏱️ ±0s
  6 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit c98efb8. ± Comparison against base commit 1711385.

♻️ This comment has been updated with latest results.

Hi @billmcspadden-riscv, this PR is failing the CI for breakpoint test in riscv test. The way I see it, when the sdtrig registers were absent, the access would just be ignored as there was no register at tdata1 and go on. but as now the register is present and is writable in debug mode only (which is still not present in SAIL-RISCV), so it gives illegal instruction exception.

Hi @billmcspadden-riscv, this PR is failing the CI for breakpoint test in riscv test. The way I see it, when the sdtrig registers were absent, the access would just be ignored as there was no register at tdata1 and go on. but as now the register is present and is writable in debug mode only (which is still not present in SAIL-RISCV), so it gives illegal instruction exception.

Either the test is wrong or your implementation is wrong. Which is it?

Either the test is wrong or your implementation is wrong. Which is it?

At a guess, the test is now wrong, because the expected outcome is "access failure" because the test assumes the register is not there. That has changed. So either remove the failing tests, or change their expected outcome.

@Mudassir10X Could you show us the source of the failing tests?

There can be 2 ways to solve this problem.

1. If the test is just checking if some CSR is defined or not, and the passing criteria is "access failure", then test is needed to be modified to change the passing criteria. The test should be considered "pass" if CSR is not defined and giving "access failure" or if CSR is defined then legal read/write should be considered as "pass".
2. Instead of checking if a certain CSR is defined or not, a test should check the valid functionality of that CSR and a flag should be added which chooses the test to be run based on the architecture state (or riscv-config string). Test will be selected only if a certain CSR is defined and accessible but if the CSR is undefined then that test should not be selected.

PS: From ACT point of view, option 2 is viable because if a CSR is not defined then you should not test any feature related to that CSR. But this case in more interesting one. In this case, a CSR (tdata1) has been defined but it is not accessible as Debug mode is not available in Sail, so now there is a CSR whose definition and mapping is available in Sail but you cant read/write it in a test because there is no legal way to access it without Debug mode. In this case, option 1 can be chosen as a short term solution.

@Mudassir10X can you please close this one, since new PR has been added.

This PR has been replaced by PR #573